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(54) Improved media streaming methods and arrangements 



(57) Methods and arrangements are provided that 
integrate media streaming and Quality of Service (QoS) 
supportive protocols, such as, e.g., Real-Time Stream- 
ing Protocol (RTSP) and Resource Reservation Proto- 
col (RSVP), respectively, in a manner that significantly 
reduces a session's startup latency as well as providing 
a higher quality of service that is experienced by an end 
user. The methods and arrangements selectively initiate 
the streaming of the media data as soon as possible, 
perhaps at an initially lower QoS, while simultaneously 
setting up a more desirable or applicable guaranteed 
QoS path. The methods and arrangements can be im- 
plemented in an intelligent manner to dynamically anoY 
or selectively modify the streaming media in response 
to various network congestion problems, etc. A different/ 
dynamic QoS capability may be setup during an existing 
streaming operation, and the streaming operation mod- 
ified accordingly once the new QoS set-up has been 
completed. The methods and arrangements can pro- 
vide such capabilities without significantly disturbing the 
user's experience. 
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Description 
TECHNICAL FIELD 

[0001] This invention relates to computers and com- 
puter networks, and more particularly to methods and 
arrangements that significantly improve the media 
streaming experience for the end user and provide sup- 
port for Quality of Service (QoS) features. 

BACKGROUND 

[0002] Computers and data communication networks 
are becoming increasing faster. One popular use for 
such high-speed devices and arrangements is to pro- 
vide a stream of data associated with one or more forms 
of media. For example, many users of the Internet se- 
lectively download or "stream" video and/or audio data 
from other computers or servers. Applications are avail- 
able to encode and stream the media data, and subse- 
quently receive and play the streamed media data for 
the user. Thus, a user may watch an encoded/streamed 
television news program, receive real time investment 
information, listen to an encoded/streamed radio shows, 
etc., over a computer network. 
[0003] Unfortunately, from time-to-time, users may 
experience an undesirable break in the streaming of the 
media data due to various reasons. For example, the 
network may become momentarily congested causing 
the loss of some of the streaming data. Much of this un- 
certainty can be resolved by adequately buffering 
streamed data on the receiving computer or like device. 
Another way to solve this problem is to provide dedicat- 
ed or otherwise guaranteed data paths through the in- 
tervening network resources. These various resources 
can be configured to provide a defined level or quality 
of service (QoS) for the streaming data. This is usually 
accomplished to support applications that require two- 
way communications, such as multiple party conferenc- 
ing applications, and the like. 
[0004] In addition to breaks in the reception of the 
streamed media data, users are often subjected to an 
initial session startup latency or delay while the various 
supporting software and hardware systems exchange 
the applicable information necessary to set-up for the 
streaming of media data and start streaming/buffering 
media data. 

[0005] The above problems and others associated 
with streaming media tend to degrade the overall end 
user experience. Consequently, there is a need for im- 
proved methods and arrangements that effectively re- 
duce the startup latency and support QoS capabilities. 

SUMMARY 

[0006] In accordance with certain aspects of the 
present invention, improved methods and arrange- 
ments are provided that integrate media streaming and 



Quality of Service (QoS) supportive protocols, such as, 
e.g., Real-Time Streaming Protocol (RTSP) and Re- 
source Reservation Protocol (RSVP), respectively, in a 
manner that significantly reduces the startup latency 
5 and improves the overall viewing experience by an end 
user. 

[0007] For example, in certain implementations, the 
methods and arrangements essentially initiate the 
streaming of the media as soon as possible, perhaps at 

10 an initially lower QoS, while simultaneously setting up a 
more desirable or applicable QoS capability. The meth- 
ods and arrangements may further be implemented in 
an intelligent manner to dynamically and/or selectively 
modify the streaming media in response to various net- 

15 work congestion problems, etc. Thus, a different/dy- 
namic QoS capability may be setup during an existing 
streaming operation, and the streaming operation mod- 
ified accordingly once the new QoS set-up has been 
completed. The various methods and arrangements 

20 provide such capabilities without significantly disturbing 
the user's experience. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 [0008] A more complete understanding of the various 
methods and arrangements of the present invention 
may be had by reference to the following detailed de- 
scription when taken in conjunction with the accompa- 
nying drawings wherein: 

30 

Fig. 1 is a block diagram depicting an exemplary 
client-server arrangement that is configurable to 
support media streaming from a server device to a 
client device, through an interconnecting network 
35 that provides selective Quality of Service (QoS) ca- 
pabilities. 

Fig. 2 is a block diagram depicting an exemplary 
computing system suitable for use as either a server 
device or as a client device in the arrangement of 

40 Fig. 1 . 

Figs. 3(a-b) are time-line graphs that illustratively 
depict certain exemplary control-based delays as- 
sociated with establishing a media-streaming ses- 
sion in the arrangement of Fig. 1 using known com- 

45 munlcatlon protocols. 

Figs. 4 Is time-line graph that illustratively depicts 
certain exemplary control-based delays associated 
with establishing a media-streaming session in the 
arrangement of Fig. 1 using exemplary techniques, 

so in accordance with certain implementations of the 
present invention. 

Fig. 5 is an event-line graph that illustratively de- 
picts the client-server arrangement of Fig. 1 estab- 
lishing an exemplary media-streaming session, in 
55 accordance with certain implementations of the 
present invention. 

Fig. 6 is a process table associated with the event- 
line graph of Fig. 5. 
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DETAILED DESCRIPTION 

[0009] Fig. 1 is a block diagram depicting an exem- 
plary client-server arrangement 1 00 that is configurable 
to support media streaming from at least one server de- 
vice 102 to at least one client device 104, through at 
least one interconnecting network 1 06 that provides se- 
lective Quality of Service (QoS) capabilities. 
[0010] As depicted in this simple arrangement, net- 
work 106 provides two-way communication between 
server device 102 and client device 1 04 through one or 
more routers 1 08 or like devices. Here, for example, net- 
work 1 06 may be a packet switched network that is con- 
figured to use Transmission Control Protocol /Internet 
Protocol (TCP/IP) to transfer information between serv- 
er device 102 and client device 104 in packets appro- 
priately addressed and delivered via the routers 108. 
Retransmission services are also provided for missing/ 
corrupted packets. These and other well known proto- 
cols and techniques can be implemented to provide spe- 
cific services between these communicating parties. 
[0011] Attention is now drawn to Fig. 2, which is a 
block diagram depicting an exemplary computing sys- 
tem 200 suitable for use as either server device 102 or 
as client device 104. Computing system 200 is, in this 
example, in the form of a personal computer (PC), how- 
ever, in other examples computing system may take the 
form of a dedicated server(s), a special-purpose device, 
an appliance, a handheld computing device, a cellular 
telephone device, a pager device, etc. 
[0012] As shown, computing system 200 includes a 
processing unit 221 , a system memory 222, and a sys- 
tem bus 223. System bus 223 links together various sys- 
tem components including system memory 222 and the 
processing unit 221 . System bus 223 may be any of sev- 
eral types of bus structures including a memory bus or 
memory controller, a peripheral bus, and a local bus us- 
ing any of a variety of bus architectures. System mem- 
ory 222 typically includes read only memory (ROM) 224 
and random access memory (RAM) 225. A basic input/ 
output system 226 (BIOS), containing the basic routine 
that helps to transfer information between elements 
within computing system 200, such as during start-up, 
is stored in ROM 224. Computing system 200 further 
Includes a hard disk drive 227 for reading from and writ- 
ing to a hard disk, not shown, a magnetic disk drive 228 
for reading from or writing to a removable magnetic disk 
229, and an optical disk drive 30 for reading from or writ- 
ing to a removable optical disk 231 such as a CD ROM 
or other optical media. Hard disk drive 227, magnetic 
disk drive 228, and optical disk drive 230 are connected 
to system bus 223 by a hard disk drive interface 232, a 
magnetic disk drive interface 233, and an optical drive 
interface 234, respectively. These drives and their as- 
sociated computer-readable media provide nonvolatile 
storage of computer readable instructions, data struc- 
tures, computer programs and other data for computing 
system 200. 



[0013] A number of computer programs may be 
stored on the hard disk, magnetic disk 229, optical disk 
231 , ROM 224 or RAM 225, including an operating sys- 
tem 235, one or more application programs 236, other 

5 programs 237, and program data 238. 

[0014] A user may enter commands and information 
into computing system 200 through various input devic- 
es such as a keyboard 240 and pointing device 242 
(such as a mouse). Of particular significance to the 

10 present invention, a camera/microphone 255 or other 
like media device capable of capturing or otherwise out- 
putting real-time data 256 can also be included as an 
input device to computing system 200. The real-time da- 
ta 256 can be input into computing system 200 via an 

is appropriate interface 257. Interface 257 can be connect- 
ed to the system bus 223, thereby allowing real-time da- 
ta 256 to be stored in RAM 225, or one of the other data 
storage devices, or otherwise processed. 
[0015] As shown, a monitor 247 or other type of dis- 

20 play device is also connected to the system bus 223 via 
an interface, such as a video adapter 248. In addition to 
the monitor, computing system 200 may also include 
other peripheral output devices (not shown), such as 
speakers, printers, etc. 

2S [0016] Computing system 200 may operate in a net- 
worked environment using logical connections to one or 
more remote computers, such as a remote computer 
249. Remote computer 249 may be another personal 
computer, a server, a router, a network PC, a peer de- 

30 vice or other common network node, and typically in- 
cludes many or all of the elements described above rel- 
ative to computing system 200, although only a memory 
storage device 250 has been illustrated in Fig. 2. 
[0017] The logical connections depicted in Fig. 2 in- 

35 elude a local area network (LAN) 251 and a wide area 
network (WAN) 252. Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, intranets and the Internet. 
[0018] When used in a LAN networking environment, 

40 computing system 200 is connected to the local network 
251 through a network interface or adapter 253. When 
used in a WAN networking environment, computing sys- 
tem 200 typically includes a modem 254 or other means 
for establishing communications over the wide area net- 

43 work 252, such as the Internet Modem 254, which may 
be internal or external, is connected to system bus 223 
via the serial port interface 246. 
[0019] In a networked environment, computer pro- 
grams depicted relative to the computing system 200, 

so or portions thereof, may be stored in the remote memory 
storage device. It will be appreciated that the network 
connections shown are exemplary and other means of 
establishing a communications link between the com- 
puters may be used. 

55 [0020] This description will now focus on certain as- 
pects of the present invention that provide for improved 
streaming media sessions. 

[0021] To establish and maintain a streaming media 
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session, server device 102, client device 104 and any 
applicable devices within network 106 will require the 
implementation of appropriate communication proto- 
cols. 

[0022] While this section of the document describes 
certain aspects of the invention through exemplary 
methods and arrangements that take advantage of well- 
known communication protocols and systems, this is by 
way of example only. Those skilled in the art will recog- 
nize that the methods and arrangements provided here- 
in are readily adaptable for implementation using these 
and/or other known or future protocols and the like. 
[0023] With this in mind, the following three related 
protocols are currently planned for streaming media da- 
ta via the Internet or other like networks: 
[0024] The first is a Reservation Protocol (RSVP), 
which is a network control protocol that deals with lower 
layer protocols having direct control over network re- 
sources. As such, RSVP is able to reserve network 1 06 
resources as required to meet a specific QoS. RSVP 
does not, however, deliver any data itself. Instead, data 
delivery is accomplished by another protocol such as 
TCP/IP, User Datagram Protocol (UDP), Real-time 
Transport Protocol (RTP), or the like. 
[0025] RTP is a transport layer protocol designed for 
transporting real-time data. Thus, RTP provides end-to- 
end delivery services, time stamping, sequence num- 
bering, etc. To provide a specific QoS, RTP could rely 
on RVSP for resource reservation. Additional data qual- 
ity and participant management can be provided 
through a Real-Tme Control Protocol (RTCP), which is 
a control part of RTP. 

[0026] The third protocol of interest with respect to ar- 
rangement 1 00 is a Real-Time Streaming Protocol (RT- 
SP), which is an application layer control protocol that 
initiates and directs delivery of streaming media from 
server device 102 to client device 104. RTSP has been 
likened to a "network VCR remote control protocoP 
since it provides the client device application/user with 
the ability to play, pause, rewind, fast forward, etc. (as 
applicable to the type of media being streamed). The 
actual data delivery is done separately, most likely by 
RTP. 

[0027] To provide a good end user experience, 
streaming media applications, such as. e.g., encoders, 
players and the like, require reservation of end-to-end 
networking resources during the streaming media ses- 
sion. The networking resources are needed to ensure 
the availability of enough bandwidth to support the traffic 
profile of the media data being streamed. 
[0028] Thus, as described above, RSVP or other like 
protocols can be employed to reserve the required 
bandwidth based on a traffic profile; RTP or other like 
protocols can be employed to transport the streaming 
media over the reserved network resources; and, RTSP 
or other like protocols can be employed to promote a 
good user end experience by providing control over the 
streaming media. 



[0029] One of the challenges facing streaming media 
appfcations and their underlying protocol stacks is the 
desire to provide the end user with a reasonably high- 
quality media data within a short amount of time follow- 

5 ing a command to begin a streaming media session. 
[0030] With this in mind, Fig. 3a is an exemplary time- 
line graph illustrating certain exemplary control-based 
delays associated with establishing a media-streaming 
session using RTSP and RTP (i.e., no QoS provided). 

10 Here, at time to, the end user (client device 1 04) initiates 
a streaming media session. From time to to time t1 , serv- 
er device 102 communicates, as needed, with client de- 
vice 1 04 and routers 1 08 to begin the session. From time 
t1 through time t2, media data is being streamed from 

15 server device 102 through one or more routers 108 to 
client device 104, where the media data is buffered. At 
time t2, enough data has been buffered to begin the 
playing of the streamed media data to the end user. 
[0031] One example of this type of streaming media 

20 session is the streaming of video and/or audio data over 
the Internet via the World Wide Web (WWW). It is not 
uncommon for end users to wait for several seconds, 
especially those communicating through lower band- 
width network resources, from when they initiate a 

25 streaming media session to when they see/hear the me- 
dia played. This wait or session start-up latency tends 
to significantly reduce the end user's experience. Addi- 
tionally, once established, the streaming media session 
will not usually have a guaranteed QoS associated with 

30 it (e.g., it will be sent best-effort). 

[0032] The time-line graph depicted in Fig. 3(b) illus- 
trates similar delays associated with an exemplary 
streaming media session, in accordance with certain im- 
plementations of the present invention, that further in- 

35 eludes a guaranteed QoS as established via RSVP 
Here, at time to, the end user (client device 1 04) initiates 
a streaming media session. From time to to time t1 , serv- 
er device 102 communicates, as needed (e.g., using 
RTSP and RTP), with client device 1 04 and routers 1 08 

40 to begin the session. From time t1 through time t2, serv- 
er device 102 further communicates/negotiates, as 
needed (e.g., using RSVP), with client device 104 and 
routers 108 to reserve the applicable network resourc- 
es. At time t2, the media data is streamed with the de- 

43 sired QoS from server device 102 through a reserved 
network path (e.g., selected routers 1 08) to client device 
104, where the media data can be immediately played 
for the end user. 

[0033] Thus, as shown in Fig. 3(b), though the end 
so user may experience a better overall QoS, there is still 
the need for the end user to wait for the media and QoS 
services to be set-up. In certain arrangements, such de- 
lays may reduce the effectiveness of the streaming me- 
dia session and/or communicated media. Therefore, it 
55 would be even more desirable to reduce the session 
startup latency. 

[0034] Attention is now directed towards Fig. 4, which 
is a time-line graph 300 that illustratively depicts the clt- 
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ent-server arrangement of Fig. 1 establishing an exem- 
plary media-streaming environment, in accordance with 
certain further implementations of the present invention. 
[0035] As shown, a media set-up delay period 302 
overlaps a QoS set-up delay period 304. The result is 
that the session startup latency experienced by the end 
user can be minimized or otherwise significantly re- 
duced. 

[0036] Continuing with the earlier example, in certain 
exemplary implementations, media set-up period 302 
would include client device 1 04 and server device 102 
exchanging RTSP commands/messages as needed to 
start or otherwise control the streaming media. QoS set- 
up period 304 would include the exchange of RSVP 
commands/messages as required to establish a guar- 
anteed QoS connection. 

[0037] Given the likelihood of variations as to when 
set-up periods 302 and 304 end (I.e., are completed), 
there are several options available for playing the 
streamed media. 

[0038] Thus, for example, if both of set-up periods 302 
and 304 end at about the same time, or if QoS set-up 
period 304 is completed prior to the end of media set- 
up period 302, then the media data can be streamed 
over the RSVP negotiated path at the guaranteed QoS 
upon the completion of media set-up period 302. 
[0039] On the other hand, if media set-up period 302 
ends prior to the completion of QoS set-up period 304, 
then the media data may be: (1) streamed over 
nonRSVP path(s) until the RSVP negotiated path is 
ready (i.e., when QoS set-up period 304 ends), which 
may require that a portion of streamed media data be 
buffered by client device 1 04 before being played for the 
end user; or (2) delayed until the RSVP negotiated path 
is ready. 

[0040] Given these choices, certain applications may 
be configured to allow the end user and/or the server 
administrator to select whether the streamed media is 
to be played as soon as possible, albeit in perhaps not 
in a preferred QoS format, or if the streamed media 
should not be played until it is in the preferred QoS for- 
mat (e.g., high-enough quality, received via the RSVP 
negotiated path, etc.). Consequently, the end user may 
experience different delays and/or played media quali- 
ties at the beginning of a streamed media session. 
[0041 ] By way of example, let us assume that an end 
user has selected to receive/play streamed video data 
as soon as possible, but would eventually like to have 
a guaranteed QoS. Let us further assume that, as a re- 
sult of network congestion or other like causes, there 
will be delay of about five seconds between the end of 
media set-up period 302 and the end of QoS set-up pe- 
riod 304. Here, the video data might therefore begin 
streaming over network 1 06 using conventional "best ef- 
fort* communications, momentarily accumulated/buff- 
ered by client device 104 (e.g., taking about two sec- 
onds), and subsequently played for the end user. 
Hence, following some delay, the end user will experi- 



ence the first three seconds of the streaming video at a 
lower quality then desired. However, once the QoS set- 
up delay period 304 has ended and the RSVP negotiat- 
ed path established, then the streaming video will be at 

5 the desired quality. 

[0042] In the above examples, set-up delay periods 
302 and 304 are essentially overlapping. However, de- 
pending upon the protocols being implemented, set-up 
delay periods 302 and 304 may be combined in an effort 

10 to further reduce the delay(s) experienced by the end 
user. 

[0043] A brief overview of RSVP signaling follows. As 
described above, RSVP is a networking protocol dedi- 
cated to being the facilitator and carrier of standardized 

is QoS information and parameters. RSVP carries generic 
(industry defined) QoS parameters from end nodes (in- 
clusive) to each QoS-aware network device included in 
the hop path between RSVP session members. That is, 
RSVP provides a way for end nodes and network devic- 

20 es to communicate and negotiate QoS parameters and 
network usage admission. 

[0044] Because RSVP is designed to carry resource 
reservation requests through networks of varying topol- 
ogies and media, an end user's QoS request is prepa- 
ys gatedto all RSVP-aware network devices alongthedata 
path, allowing resources to be reserved from all of those 
which are RSVP-enabled, at all network levels. This 
tends to allow network 106 to meet the desired level of 
service. 

30 [0045] RSVP reserves network resources by estab- 
lishing flows end to end through network 106. A flow is 
basically a network path associated with one or more 
senders, one or more receivers, and a certain QoS. A 
sending host wishing to send data that requires a certain 

35 QoS will broadcast, via the QoS Service Provider, 
"PATH" messages toward the intended recipients. 
These path messages, which describe the bandwidth 
requirements and relevant parameters of the data to be 
sent, are propagated along the path. 

40 [0046] A receiving host, interested in this particular 
data, will reserve the resources for the flow (and the net- 
work path) by sending "RESV* messages through the 
network back toward the sender. As this occurs, inter- 
mediate RSVP-capable nodes, based on bandwidth ca- 

45 paclty and policies, decide whether or not to accept the 
proposed reservation and commit resources. If an af- 
firmative decision is made, the resources are committed 
and RESV messages are propagated to the previous 
hop on the path from source to destination. 

so [0047] At the heart of the RSVP protocol is the ex- 
change of PATH and RESV messages. The PATH mes- 
sage describes the QoS parameters of the traffic, the 
sender's address, and the destination of the traffic. The 
RESV message describes the QoS parameters of the 

55 traffic to be received and the source of the traffic and is 
sent toward the sender. 

[0048] Upon receiving the RESV message, the QoS 
data flow begins. Typically, a QoS service provider con- 
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structs and periodically updates the PATH and RESV 
messages on behalf of the application. Sending appli- 
cations, such as those controlling multicast transmis- 
sions, can also be configured to begin sending immedi- 
ately on a best effort basis, which can then upgraded to 
QoS on receipt of the RESV message. 
[0049] Reference is now made to the exemplary com- 
bined message flow in the event-line graph depicted in 
Fig. 5 and further summarized in an associated table in 
Fig. 6. 

[0050] In this example, a RSVP enabled streaming 
media session is set-up by a sequence of RTSP mes- 
sages and RSVP messages, depicted as solid-line ar- 
rows and dashed-line arrows, respectively, between cli- 
ent device 104 and server device 102. The curved ar- 
rows show the event dependencies for the various mes- 
sages. 

[0051] Client device 1 04 initiates the session set-up 
by sending RTSP SETUP commands, one for each me- 
dia stream being set-up, to server device 1 02. After the 
iast SETUP command, client device 1 04 sends an RT- 
SP S ET_PARAMETER command, which initiates the 
RSVP signaling. Upon receiving the 
S ET_PARAMETER command, server device 1 02 sends 
out an RSVP PATH message. After sending the 
S ET_PARAM ETE R command, client device 104 goes 
ahead and sends out the RTSP PLAY command, and 
server device 102 starts sending data upon receiving 
this PLAY command. 

[0052] Upon receiving the PATH message, client de- 
vice 1 04 sends an RSVP RESV message to server de- 
vice 102, to which server device 102 replies with an 
RSVP RESV CONF message. The media data output 
by server device 102 is sent best effort until the RESV 
message is received. Once the RESV message is re- 
ceived, the streaming media data flow is changed to a 
guaranteed QoS. 

[0053] A similar process is presented in the table de- 
picted in Fig. 6. It should be noted that the listed steps 
may occur in a different ordering and/or that some of the 
steps may be left out of the process in other implemen- 
tations/cases. Here, in the direction column, "C" repre- 
sents client device 104, "S" represents server device 
102, the presence of a pointer represents the direction 
Information flow, the lack of a pointer represents that the 
action occurs within the identified device. 
[0054] In the remark column, as noted, client device 
1 04 may receive an FD_QOS notification with the avail- 
able network bandwidth when it receives the PATH mes- 
sage from server device 1 02. If the available bandwidth 
is lower than the bandwidth requested by server device 
1 02, then client device 1 04 may either continue the ses- 
sion without a reservation or otherwise terminate the re- 
quest. 

[0055] To further reduce the session startup latency 
in a LAN or other like environment wherein the network 
bandwidth is typically significantly greater than the 
streaming media requires, server device 102 may be 



configured to initially stream the data at a higher rate 
than the actual stream rate untB client device's startup 
buffer is full. As such, client device 104 could start play- 
ing back the streamed media data earlier than as nor- 
5 maiiy would be the case. A separate reliable (TCP) con- 
nection, for example, could be used to send the initial 
fast-start related media data from server device 1 02 to 
client device 104. 

[0056] In such an accelerated streaming case, for ex- 
10 ample, client device 104 could reserve a bandwidth, 
which is equal to the highest bandwidth of the media 
stream data that can be requested by the client. The in- 
teraction of the server transmissions and the RSVP res- 
ervations happen in the same way as mentioned above 
15 for a normal media streaming case, except that the serv- 
er side transmissions of data can also take place now 
at the accelerated bit rate. 

[0057] This supports best effort streaming of the re- 
quested accelerated stream with greater than real-time 

20 bandwidth, for example, in case the current RSVP res- 
ervation is insufficient to support the requested band- 
width. This behavior of sending best-effort streams until 
the RSVP reservation is completed will be permitted in 
case the encoder/server configuration hasn't disabled a 

25 -Do best effort delivery in case RSVP reservation fails" 
(e.g., "Play as soon as possible") setting. Otherwise, 
server device 102 will wait for the RSVP reservation to 
be re-established and re-negotiate before resuming the 
data sending process. 

30 [0058] The various aforementioned techniques also 
support dynamic communication changes associated 
an ongoing streaming media session. Thus, for exam- 
ple, RSVP or other like protocol signaling can be used 
to lower and/or raise the QoS associated the streaming 

35 media based on availability/congestion information from 
network 106. 

[0059] For example, in the case that there is a need 
to switch streams to a lower bandwidth stream within a 
program due to network conditions, the initial reserva- 

40 tion is left unchanged and a traffic shaping or similar 
function at server device 102 is changed to the new 
bandwidth. As long as the bandwidth is not greater than 
the initial reservation, server device 102 can configure 
the traffic shaping to different bandwidths without the 

45 need for any further RSVP signaling. 

[0060] If there is a need to switch the stream band- 
width to a value higher than the currently negotiated val- 
ue, then server device 1 02 will start sending the media 
data in best effort mode, while negotiating for a RSVP 

so stream flow in parallel. This behavior of sending best- 
effort streams until the RSVP reservation is complete is 
permitted in case the encoder/server configuration 
hasnl disabled the "Do best effort delivery in case RSVP 
reservation fails" setting. Otherwise, server device 102 

55 will wait for the RSVP reservation to be re-established 
and re-negotiated before sending data at the higher 
rate. 

[0061] Support is also available for server side play 
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lists that allow server device 1 02 to stream a plurality of 
media streams over the same data session one after 
another Similarly, client side play lists allow client de- 
vice 104 to play different media streams one after an- 
other in a single play session. 
[0062] The different streams in the play lists could 
have varying bandwidth requirements. As a result, there 
may be a need to change the reservation for each new 
stream. To make the switch seamless, a change in 
RSVP reservation can be made, for example, about 1 0 
seconds in advance of the actual stream switch, when- 
ever possible. 

[0063] Thus, if the required bandwidth for the next 
item in the play list is lower than the currently negotiated 
bandwidth, then traffic shaping may be done on the 
server end to send the data without renegotiating the 
RSVP reservation for the flow. If the required bandwidth 
for the next Item in the play list is higher than the cur- 
rently negotiated bandwidth, then send best-effort me- 
dia data until the RSVP reservation is complete. A par- 
allel negotiation can occur for a RSVP connection, fol- 
lowed by a switch to a RSVP flow once the reservation 
comes through. 

[0064] This behavior of sending best-effort streams 
until the RSVP reservation is complete will be permitted 
incase the encoder/server configuration hasn't disabled 
the "Do best effort delivery in case RSVP reservation 
fails" setting. Otherwise, server device 102 will wait for 
the RSVP reservation to be reestablished and re-nego- 
tiated before resuming the data sending process for the 
next item in the play list. 

[0065] The reservation for the new stream will be ini- 
tiated, for example, about 10 seconds before the old 
stream ends. This would be at the time when server de- 
vice 102 receives the SETUP for the new stream. The 
reservation forthe new stream overrides the reservation 
for the old stream. 

[0066] Server device 102 may also send out PATH 
messages by default for session less multicast sessions 
(done by default by the service provider). Once a client 
device 104 retrieves the announcement information, in- 
cluding the multicast address and port number informa- 
tion, it can then send out a RSVP RESV message to 
server device 1 02 requesting networking and host re- 
sources for the traffic profile. Thereafter, the server-cli- 
ent streaming media session progresses similar to the 
unicast cases described above. The various techniques 
also pertain to RTSP or other like protocol based ses- 
sion full-multicast support during multimedia streaming. 
[0067] Although some preferred embodiments of the 
various methods and arrangements of the present in- 
vention have been illustrated in the accompanying 
Drawings and described in the foregoing Detailed De- 
scription, it will be understood that the invention is not 
limited to the exemplary embodiments disclosed, but is 
capable of numerous rearrangements, modifications 
and substitutions without departing from the spirit of the 
invention as set forth and defined by the following 
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Claims 

5 

1. A method for initiating a streaming media transfer 
between a server device and a client device through 
at least one interconnecting network, the method 
comprising: 

w 

selectively transferring an initial portion of a 
stream of data from a server device to a client 
device via a plurality of network resources; 
establishing a guaranteed quality of service 
15 path from the server device to the client device 

via a portion of the plurality of network resourc- 
es; and 

selectively transferring a subsequent portion of 
the stream of data over the guaranteed quality 
20 of service path from the server device to the cli- 

ent device. 

2. The method as recited in Claim 1 , wherein selec- 
tively transferring the initial stream of data from the 

25 server device to the client device occurs, at least 
partially, while establishing the guaranteed quality 
of service path from the server device to the client 
device. 

30 3. The method as recited in Claim 1 , wherein selec- 
tively transferring the initial stream of data from the 
server device to the client device occurs until the 
guaranteed quality of service path from the server 
device to the client device has been established. 

35 

4. The method as recited in Claim 1 , wherein selec- 
tively transferring the initial stream of data from the 
server device to the client device further includes 
establishing a data connection using afirst protocol, 
40 and wherein establishing the guaranteed quality of 
service path from the server device to the client de- 
vice further includes establishing a guaranteed flow 
specification using a second protocol. 

43 s. The method as recited In Claim 4, wherein the first 
protocol includes a Real-Time Streaming Protocol 
(RTSP). 

6. The method as recited in Claim 4, wherein the sec- 
50 ond protocol includes a Resource Reservation Pro- 
tocol (RSVP). 

7. The method as recited in Claim 1 , wherein the initial 
portion of the stream of data is transferred over the 

55 plurality of network resources at a first level of qual- 
ity of service, and the subsequent portion of the 
stream of data is transferred over the guaranteed 
quality of service path at a second level of quality 
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of service that is higher than the first level of quality 
of service. 

8. A computer-readable medium having computer-ex- 
ecutable instructions for performing steps that initi- 
ate a streaming media transfer between a server 
device and a client device through at least one in- 
terconnecting network, the steps comprising: 

selectively transferring an initial portion of a 
stream of data from a server device to a client 
device via a plurality of network resources; 
establishing a guaranteed quality of service 
path from the server device to the client device 
via a portion of the plurality of network resourc- 
es; and 

selectively transferring a subsequent portion of 
the stream of data over the guaranteed quality 
of service path from the server device to the cli- 
ent device. 

9. The computer-readable medium as recited in Claim 
8, wherein selectively transferring the initial stream 
of data from the server device to the client device 
occurs, at least partially, while establishing the 
guaranteed quality of service path from the server 
device to the client device. 

10. The computer-readable medium as recited in Claim 
8, wherein selectively transferring the initial stream 
of data from the server device to the client device 
occurs until the guaranteed quality of service path 
from the server device to the client device has been 
established. 

1 1 . The computer-readable medium as recited in Claim 
8, wherein selectively transferring the initial stream 
of data from the server device to the client device 
further includes establishing a data connection us- 
ing a first protocol, and wherein establishing the 
guaranteed quality of service path from the server 
device to the client device further includes estab- 
lishing a guaranteed flow specification using a sec- 
ond protocol. 

12. The computer-readable medium as recited in Claim 
11 , wherein the first protocol includes a Real-Time 
Streaming Protocol (FTTSP). 

13. The computer-readable medium as recited in Claim 
11, wherein the second protocol includes a Re- 
source Reservation Protocol (RSVP). 

14. The computer-readable medium as recited in Claim 
8, wherein the initial portion of the stream of data is 
transferred over the plurality of network resources 
at a first level of quality of service, and the subse- 
quent portion of the stream of data is transferred 



over the guaranteed quality of service path at a sec- 
ond level of quality of service that is higher than the 
first level of quality of service. 

5 15. A server device suitable for use in initiating a 
streaming media transfer to a client device through 
at least one interconnecting network, the server de- 
vice comprising: 

w memory containing at least a portion of a 

stream of data; and 

logic operative ly coupled to the memory and 
configurable to 

15 selectively output an initial portion of the 

stream of data from the memory to a client 
device, 

support the establishment of a guaranteed 
quality of service path to the client device; 
20 and 

selectively output a subsequent portion of 
the stream of data over the guaranteed 
quality of service path to the client device. 

25 16. The server device as recited in Claim 15, wherein 
the logic is further configurable to simultaneously 
transfer the initial stream of data to the client device 
and establish the guaranteed quality of service 
path. 

30 

17. The server device as recited in Claim 15, wherein 
the logic is further configurable to transfer the initial 
stream of data to the client device until the guaran- 
teed quality of service path to the client device has 

35 been established. 

18. The server device as recited in Claim 15, wherein 
the logic is further configurable to establish a data 
connection using a first protocol, and a guaranteed 

40 flow specification using a second protocol. 

19. The server device as recited in Claim 18, wherein 
the first protocol includes a Real-Time Streaming 
Protocol (RTSP). 

45 

20. The server device as recited in Claim 18, wherein 
the second protocol includes a Resource Reserva- 
tion Protocol (RSVP). 

50 21. The server device as recited in Claim 15, wherein 
the logic is configurable to transfer the initial portion 
of the stream of data at a first level of quality of serv- 
ice, and the subsequent portion of the stream of da- 
ta at a second level of quality of service that is higher 

55 than the first level of quality of service. 

22. A client device suitable for use in initiating a stream- 
ing media transfer from a server device through at 
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least one interconnecting network, the client device 
comprising: 

memory suitable for containing at least a por- 
tion of a stream of data; and 5 
logic operative^ coupled to the memory and 
configurable to 

selectively receive an initial portion of the 
stream of data from the server device, 10 
support the establishment of a guaranteed 
quality of service path from the server de- 
vice; and 

selectively receive a subsequent portion of 
the stream of data over the guaranteed 
quality of service path from the server de- 
vice. 

23. The client device as recited in Claim 22, wherein 

the logic is further configurable to simultaneously 20 
receive the initial stream of data from the server de- 
vice and establish the guaranteed quality of service 
path. 

24. The client device as recited in Claim 22, wherein 25 
the logic is further configurable to receive the initial 
stream of data from the server device until the guar- 
anteed quality of service path from the server de- 
vice has been established. 

30 

25. The client device as recited in Claim 22, wherein 
the logic is further configurable to establish a data 
connection using a first protocol, and a guaranteed 
flow specification using a second protocol. 

35 

26. The client device as recited in Claim 25, wherein 
the first protocol includes a Real-Time Streaming 
Protocol (FTTSP). 

27. The client device as recited in Claim 25, wherein *o 
the second protocol includes a Resource Reserva- 
tion Protocol (RSVP). 

28. The client device as recited in Claim 22, wherein 

the logic is configurable to receive the initial portion 45 
of the stream of data at a first level of quality of serv- 
ice, and the subsequent portion of the stream of da- 
ta at a second level of quality of service that is higher 
than the first level of quality of service. 
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Server Device 



Information Exchanged 



Client Device 




* specifying options, such as, e.g., to wait 
for RESV before sending media data, 
never send best-effort, eta 
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Step I 


Diection 1 


Action 1 


[l [ 


c->s 1 


Create a RTSP control connection ever TCP 

. 1 

• ♦ 1 




C->S [ 


Send RTSP SETUP request with the send best- 
effort data option for every stream in the program . 


fa 


C->S 


Send a RTSP SETJRARAMETER request to the 

earviAr bniruvfi^oh/ sift AT thft SETUP ITieS$3Q6. I 

server tTuneowtH/ «ua um wr * 


1 


S-> c 


1 /UAH 1 inD A~A*% esvifat QanH RSVP PATH 1 
Open UDK Oota SOCKou oenu rw»r rr***f 1 

message. Send RTSP SETUP reply. 




|c 


1 Receive RTSP SETUP reply. 


|8 


lc->s 


1 Send RTSP PLAY request. 


17. 


|s->c 


1 Send RTSP PLAY reply. Send Data best-effort 


Is. 


|c 


9 Receive Data best-effort 

1 1 
1 


|9. 


Tc 


1 Receive RSVP PATH message. 



Remark 



Client receives 
FD_QOS 
notification 



10. c->s 



Send RSVP RESV message. 



11. S 



12. S->C 



13. C 



Receive RSVP RESV message. Change setting to 
guaranteed. 

Send RSVP RESV CONF message. Send Data 
guaranteed. 

Receive RSVP RESV CONF message. Receive I FD.QOS 
Data. 1 notification 



5^, 6 

14 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. . 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



